La accesibilidad web dejó de ser un “extra” hace años. Con la entrada en vigor de la Directiva Europea 2016/2102 y la progresiva adopción del European Accessibility Act, cumplir WCAG 2.1 nivel AA pasó de ser una buena práctica a un requisito legal para muchas organizaciones. Y sin embargo, muchos equipos de desarrollo siguen enfrentando la accesibilidad como un proyecto gigante e inabordable. Este artículo propone un camino pragmático para cubrir WCAG sin desesperarte.
Los cuatro principios que vertebran WCAG
WCAG se articula alrededor de cuatro principios, recordados por el acrónimo POUR (Perceivable, Operable, Understandable, Robust). En español los llamamos perceptible, operable, comprensible y robusto. Cada principio se descompone en pautas, y cada pauta en criterios de éxito etiquetados con un nivel de conformidad (A, AA o AAA).
El nivel AA es el objetivo práctico: incluye todo lo del nivel A y añade los criterios que cubren la inmensa mayoría de necesidades reales de accesibilidad. El nivel AAA existe, pero en muchos casos es inalcanzable sin sacrificar otras dimensiones del producto.
Empezar leyendo los 50 criterios de nivel AA es, en efecto, abrumador. La buena noticia es que no tienes que resolverlos todos a la vez.
Un camino incremental en tres capas
En lugar de tratar WCAG como un check gigantesco, conviene organizarlo en tres capas que coinciden con tres tipos de trabajo distintos.
Capa 1: el HTML semántico
Aproximadamente el 40% de los criterios de WCAG se resuelven escribiendo HTML correctamente. Usar <button> en vez de <div onclick>, poner <label> a cada <input>, respetar la jerarquía de encabezados (<h1> → <h2> → <h3>), asociar las tablas con <th scope="col">, añadir atributos alt a las imágenes significativas y alt="" a las decorativas.
Este trabajo no requiere librerías ni herramientas: requiere disciplina y una revisión sistemática del marcado existente. Es también la capa que más impacto tiene sobre usuarios de lectores de pantalla, navegación por teclado y modos de alto contraste. Si no haces nada más, haz esto.
Capa 2: el comportamiento con JavaScript
La segunda capa aparece cuando el HTML por sí solo no basta: menús desplegables, diálogos modales, pestañas, comboboxes personalizados. Aquí es donde entra ARIA Authoring Practices Guide, que documenta patrones probados de interacción accesible para cada componente compuesto.
La regla de oro de ARIA es: no uses ARIA si puedes evitarlo. Un <button type="button"> nativo accesible es siempre preferible a un <div role="button" tabindex="0" aria-pressed="false"> artesanal. Pero cuando no queda más remedio, ARIA da el vocabulario para comunicar estados y roles al árbol de accesibilidad.
Componentes de librerías maduras como Radix UI, Headless UI o React ARIA resuelven gran parte de este trabajo con implementaciones probadas, incluyendo gestión de foco, navegación por teclado y anuncios de lector de pantalla.
Capa 3: el contenido
El tercer bloque es el que suele sorprender a los equipos técnicos: WCAG tiene criterios sobre el contenido, no solo sobre el código. El contraste de color, la legibilidad del texto, los subtítulos de los vídeos, las transcripciones de los audios, las instrucciones que no dependen únicamente de color o forma. Estos criterios requieren involucrar a diseñadores, redactores y equipos de producto, no solo a desarrollo.
Como señalamos en la elección de palabras en tu aplicación, el lenguaje claro es parte de la accesibilidad: textos simples, frases cortas y terminología consistente benefician especialmente a usuarios con discapacidades cognitivas.
Herramientas prácticas
Ninguna herramienta automatizada puede detectar más allá del 30–40% de los problemas de accesibilidad — los expertos de Deque han documentado este techo con cierta frecuencia —, pero sí ayudan a cortar el trabajo manual a la mitad. Las tres que recomiendo integrar desde el primer día:
- axe de Deque: motor de auditoría usado por docenas de herramientas. Existe como extensión de navegador, integración de Cypress/Playwright y acción de CI. Encuentra lo que cualquier auditor detectaría en su primera pasada.
- WAVE de WebAIM: ideal para auditorías visuales rápidas. Sobreimprime iconos sobre la página indicando problemas, lo que hace sencilla la comunicación con equipos no técnicos.
- Lighthouse de Chrome: integrado en las DevTools, cubre una subset del conjunto de reglas de axe. Útil como guardarraíl continuo.
Añade además una revisión manual con teclado (navegar la aplicación entera sin ratón) y una pasada con un lector de pantalla — NVDA en Windows, VoiceOver en macOS — al menos una vez por iteración. Ningún test automático sustituye este paso.
Flujo de trabajo recomendado
Para equipos que parten de cero, el orden que menos fricciones genera es:
- Auditoría inicial con axe o WAVE sobre las 5–10 vistas más críticas. Clasifica los hallazgos por criterio de éxito WCAG.
- Tres sprints de HTML semántico: arreglar labels, headings, alt-text, foco visible, contraste. Sin diseño nuevo, sin código nuevo — solo corrección.
- Incorporación de librerías accesibles para los componentes compuestos que implementa el equipo: diálogos, menús, tabs.
- Integración de axe en CI (regla: bloquear merge si aparecen errores de nivel crítico). Esto evita retrocesos.
- Checklist manual como la de A11y Project antes de cada release, complementada con la prueba de teclado + lector de pantalla.
Este camino, ejecutado con disciplina, lleva a la mayoría de aplicaciones a cumplir WCAG 2.1 AA en 2–3 meses. No es rápido, pero tampoco es el proyecto infinito que muchos temen.
Errores frecuentes que conviene evitar
Al acompañar proyectos en esta transición, hay cuatro patrones problemáticos que aparecen una y otra vez:
- Tratar la accesibilidad como una auditoría puntual, en lugar de una práctica continua. Sin CI, los errores vuelven a aparecer en cada sprint.
- Confundir “pasa Lighthouse 100” con “es accesible”. Lighthouse no detecta ni la mitad de los problemas reales — ayuda a bajar el nivel del ruido, no garantiza calidad.
- Añadir
aria-labela todo por si acaso. Unaria-labelredundante puede hacer que el lector de pantalla anuncie información dos veces. El “ARIA cuanto menos mejor” también aplica. - Probar solo con un lector de pantalla. NVDA, JAWS y VoiceOver interpretan algunos patrones de forma distinta. Si tu público objetivo es amplio, prueba con al menos dos.
Más en general, la accesibilidad conecta con el pensamiento de diseño: es una competencia transversal, no un chequeo final.
Conclusión
WCAG 2.1 AA es alcanzable si se ataca por capas: primero el HTML semántico, después el comportamiento dinámico, después el contenido. Con axe en CI, una librería accesible para los componentes complejos y un checklist manual por release, la mayoría de equipos llega al cumplimiento sin necesidad de grandes reestructuraciones.
Síguenos en jacar.es para más sobre accesibilidad, desarrollo frontend y buenas prácticas de diseño.
